Интеграция VMware vCenter Server с Active Directory (AD) позволяет централизовать управление учетными записями и упростить администрирование доступа. Вместо локальной базы пользователей vCenter можно использовать доменную инфраструктуру AD или другой LDAP-сервис как единый источник аутентификации. Это означает, что администраторы vSphere смогут применять те же учетные записи и группы, что и для остальных ресурсов сети, для доступа к объектам vSphere.

В данной статье описывается, как развернуть дома полноценную лабораторию VMware Cloud Foundation (VCF) на одном физическом компьютере. Мы рассмотрим выбор оптимального оборудования, поэтапную установку всех компонентов VCF (включая ESXi, vCenter, NSX, vSAN и SDDC Manager), разберем архитектуру и взаимодействие компонентов, поделимся лучшими практиками...

Если логи вашего vCenter переполнены сообщениями ApiGwServicePrincipal об истечении срока действия токенов, вы не одиноки. Частые записи уровня «info» в файле apigw.log могут засорять вашу систему, затрудняя выявление реальных проблем. К счастью, есть простое решение: измените уровень логирования с «info» на «error». Автор блога cosmin.us подробно рассказал, как именно можно эффективно уменьшить количество этих лишних записей в журнале.

Со стороны сервера VMware vCenter в логе вы можете увидеть записи следующего вида:

The token with id '_9eb499f7-5f0e-4b83-9149-e64ae5bbf202' for domain vsphere.local(9d121150-d80b-4dbe-8f8a-0254435cf32a) is unusable (EXPIRED). Will acquire a fresh one.

Эти сообщения появляются потому, что по умолчанию для файла apigw.log установлен уровень логирования «info». В результате регистрируется каждое истечение срока действия и обновление токена — обычный процесс, который не требует постоянного внимания. Итог — перегруженные журналы и возможное снижение производительности. Изменив уровень логирования на «error», вы сможете ограничить записи в журналах только критически важными проблемами.

Внимательно следуйте данным инструкциям, чтобы изменить уровень логирования для apigw.log. Этот процесс применим как к отдельным серверам vCenter, так и к серверам в режиме Enhanced Linked Mode.

1. Создание снапшота сервера vCenter

   Перед внесением изменений защитите свою среду, создав снапшот vCenter. Если ваши серверы vCenter работают в режиме Enhanced Linked Mode, используйте оффлайн-снапшоты для обеспечения согласованности всех узлов. Этот снимок послужит вариантом отката, если что-то пойдёт не так.

2. Резервное копирование оригинального конфигурационного файла

   Войдите на устройство vCenter Server Appliance (VCSA) по SSH с правами root. Выполните следующую команду для резервного копирования файла vmware-services-vsphere-ui.conf:

cp /etc/vmware-syslog/vmware-services-vsphere-ui.conf /etc/vmware-syslog/vmware-services-vsphere-ui.conf.backup

Это создаст резервную копию (vmware-services-vsphere-ui.conf.backup), к которой можно вернуться при необходимости.

3. Редактирование конфигурационного файла логирования
   
   Откройте конфигурационный файл с помощью редактора vi:

vi /etc/vmware-syslog/vmware-services-vsphere-ui.conf

Нажмите i для перехода в режим вставки. Найдите строку, задающую уровень логирования для apigw.log, обычно это:

#vsphere-ui apigw log input(type="imfile" File="/var/log/vmware/vsphere-ui/logs/apigw.log" Tag="ui-apigw" Severity="info" Facility="local0")

Измените «info» на «error», чтобы получилось:

#vsphere-ui apigw log input(type="imfile" File="/var/log/vmware/vsphere-ui/logs/apigw.log" Tag="ui-apigw" Severity="Error" Facility="local0")

Теперь vCenter будет записывать в apigw.log только ошибки.

4. Сохранение изменений и выход из редактора

   Нажмите Esc, чтобы выйти из режима вставки. Введите :wq! и нажмите Enter, чтобы сохранить изменения и закрыть редактор.

5. Перезапуск сервисов vCenter

   Чтобы изменения вступили в силу, перезапустите службы vsphere-ui и vmware-stsd следующими командами:

service-control --restart vsphere-ui service-control --restart vmware-stsd

Перезапуск этих служб активирует новые настройки логирования.

Проверка результата

После перезапуска сервисов убедитесь, что избыточные сообщения об истечении срока действия токенов прекратились. Теперь при уровне логирования «error» будут появляться только критические проблемы, делая ваши журналы более понятными и полезными.

Недавно мы писали о том, что команда ESXi-Arm выпустила новую версию популярной платформы виртуализации ESXi-Arm Fling (v2.0) (ссылка на скачивание тут), которая теперь основана на базе кода ESXi версии 8.x и конкретно использует последний релиз ESXi-x86 8.0 Update 3b.

Вильям Лам рассказал о том, что теперь вы можете запустить экземпляр ESXi-Arm V2 внутри виртуальной машины, что также называется Nested ESXi-Arm. На конференции VMware Explore в США он использовал Nested ESXi-Arm, так как у него есть ноутбук Apple M1, и ему нужно было провести демонстрацию для сессии Tech Deep Dive: Automating VMware ESXi Installation at Scale, посвященной автоматизированной установке ESXi с помощью Kickstart. Поскольку и ESXi-x86, и ESXi-Arm имеют одинаковую реализацию, возможность запуска Nested ESXi-Arm оказалась полезной (хотя он использовал версию, отличающуюся от официального релиза Fling). Такой же подход может быть полезен, если вы хотите запустить несколько виртуальных машин ESXi-Arm для изучения API vSphere и подключить Nested ESXi-Arm к виртуальной машине x86 VCSA (vCenter Server Appliance). Возможно, вы разрабатываете что-то с использованием Ansible или Terraform - это действительно открывает множество вариантов для тех, у кого есть такая потребность.

Arm Hardware

Так же как и при создании Nested ESXi-x86 VM, выберите опцию типа ВМ "Other" (Другое) и затем выберите "VMware ESXi 8.0 or later", настроив как минимум на 2 виртуальных процессора (vCPU) и 8 ГБ оперативной памяти.

Примечание: Текущая версия ESXi-Arm НЕ поддерживает VMware Hardware-Assisted Virtualization (VHV), которая необходима для запуска 64-битных операционных систем в Nested или внутренних виртуальных машинах. Если вы включите эту настройку, запустить Nested ESXi-Arm VM не получится, поэтому убедитесь, что эта настройка процессора отключена (по умолчанию она отключена).

VMware Fusion (M1 и новее)

Еще одна хорошая новость: для пользователей Apple Silicon (M1 и новее) теперь также можно запускать виртуальные машины Nested ESXi-Arm! Просто выберите «Other» (Другое), затем тип машины «Other 64-bit Arm» и настройте ВМ с как минимум 2 виртуальными процессорами (vCPU) и 8 ГБ оперативной памяти. Вильяму как раз потребовалась эта возможность на VMware Explore, когда он демонстрировал вещи, не связанные напрямую с архитектурой Arm. Он попросил команду инженеров предоставить внутреннюю сборку ESXi-Arm, которая могла бы работать на Apple M1, теперь же эта возможность ESXi-Arm доступна для всех.

Примечание: поскольку для работы Nested-ESXi-Arm требуется режим promiscuous mode, при включении виртуальной машины в VMware Fusion вас могут раздражать запросы на ввод пароля администратора. Если вы хотите отключить эти запросы, ознакомьтесь с этой статьей в блоге для получения дополнительной информации.

Если вы пропустили новость о том, что вышло обновление платформы VMware vSphere 8 Update 3b, то сейчас самое время подумать об обновлении, так как сообщений о каких-то серьезных багах не поступало.

Итак, что нового в VMware ESXi 8.0 Update 3b:

• DPU/SmartNIC - появилась поддержка VMware vSphere Distributed Services Engine с DPU NVIDIA Bluefield-3. Устройства DPU NVIDIA Bluefield-3 поддерживаются как в режиме одиночного DPU, так и в dual-DPU конфигурациях.
• ESXi 8.0 Update 3b добавляет поддержку vSphere Quick Boot для нескольких серверов, включая:
  • HPE ProLiant DL145 Gen11
  • HPE ProLiant MicroServer Gen11
  • Cisco UCSC-C245-M8SX
  • Supermicro AS-2025HS-TNR

Для полного списка поддерживаемых серверов смотрите VMware Compatibility Guide.

• Улучшения в проектировании переменных cloud-init guestInfo: начиная с ESXi 8.0 Update 3b, попытка обычных пользователей задать переменные cloud-init guestInfo внутри гостевой ОС приводит к ошибке. Для получения дополнительной информации см. KB 377267.

Что нового в VMware vCenter 8.0 Update 3b:

• Этот выпуск устраняет уязвимости CVE-2024-38812 и CVE-2024-38813. Для получения дополнительной информации об этих уязвимостях и их влиянии на продукты VMware посмотрите статью VMSA-2024-0019.
• VMware vCenter Server 8.0 Update 3b предоставляет исправления ошибок, описанные в разделе Resolved Issues.
• Для информации об обновлениях VMware vSphere with Tanzu смотрите Release Notes для VMware vSphere IaaS Control Plane 8.0.
• Для информации об обновлениях Photon OS смотрите обновления безопасности VMware vCenter Server Appliance Photon OS.

Если вы не знаете, как скачать VMware vSphere 8 Update 3b, воспользуйтесь информацией по этой ссылке.

На днях компания VMware выпутсила большое обновление утилиты vSphere Diagnostic Tool версии 2.0.1, которая теперь называется VCF Diagnostic Tool for vSphere (VDT). Напомним, что это python-скрипт, который запускает диагностические команды на виртуальном модуле Photon OS (на его базе построен, например, vCenter Server Appliance, где скрипт и нужно запускать), а также в перспективе это будет работать и в среде VMware ESXi. О предыдущем обновлении vSphere Diagnostic Tool (VDT) мы писали вот тут.

VDT 2 был переписан с нуля с целью эволюции от простой коллекции скриптов на Python к фреймворку для отчётности о состоянии инфраструктуры на основе Python. Новая версия предоставляет библиотеки, которые стандартизируют вывод и формат каждой проверки. Это означает, что скоро будет доступна совместимость с дополнительными продуктами от VMware.

Итак, с помощью скрипта вы сможете выполнить следующие проверки состояния инфраструктуры:

• Вывод базовой информации о vCenter
• Проверки SSO (Lookup Service и Machine ID)
• Интеграция с Active Directory
• Сертификаты vCenter
• Функциональность VMdir
  
• Core-файлы
• Использование базы данных vPostgres
• Использование дискового пространства
• Функционирование DNS
• Синхронизация времени и функционирование NTP
• Валидность аккаунта Root
• Службы vCenter
• Проверка механизма VCHA
  
• Функционирование Syslog
• Проверки IWA/AD
• Проверка Local Identity Source

Для начала работы вы можете воспользоваться следующими статьями базы знаний VMware

• Using the VCF Diagnostic Tool for vSphere (VDT) (83896)
• Using the VCF Diagnostic Tool on SDDC Manager (94141)

Скачать VCF Diagnostic Tool for vSphere можно из KB 83896 в правой колонке:

Утилита VDT запускается простой командой из консоли:

При работе скрипта будет запрошен пароль для учетной записи administrator@sso.domain, но и без него многие проверки будут выполнены успешно.

Давно мы не писали о сбросе паролей элементов виртуальной инфраструктуры VMware vSphere. Сегодня мы поговорим о том, как сделать это для основного компонента - виртуального модуля vCenter Server Appliance (vCSA), который построен на базе операционной системы Photon OS.

Об этой процедуре рассказали в блоге vTechSummary, приведем ее вкратце ниже.

Во время установки vCenter Server Appliance мы задаем пароль Root, с которым мы можем получать доступ в графическую консоль vCenter Management (VAMI) и командную строку.

По умолчанию задано устаревание пароля в 90 дней. Это можно изменить, выставив Password expires в значение No:

Если пройдет 90 дней, и вы не смените пароль, то при попытке логина в VAMI вы увидите вот такой экран:

Если вы просто забыли пароль Root, то будет вот так:

1. Вы помните пароль root, но он устарел

В этом случае мы сможем залогиниться в консоль VCSA и по SSH для смены пароля.

Открываем консоль VCSA, нажимаем F2, после чего мы можем ввести пароль. В этом случае устаревший пароль подойдет:

После этого переходим в раздел Configure Root Password, где можно поменять пароль:

Второй способ - это зайти в консоль сервера vCenter по SSH. Для смены пароля можно использовать следующую команду:

# passwd root

2. Вы не помните пароль root

Перезагрузите сервер vCenter Server Appliance и после того, как система Photon OS стартанет, нажмите клавишу <e>, чтобы зайти в редактор загрузчика GNU GRUB.

Найдите строчку, которая начинается словом linux, и добавьте в ее конец следующую строчку:

rw init=/bin/bash

После этого нажмите кнопку F10 для продолжения загрузки.

Затем вам нужно будет последовательно ввести две следующих команды:

mount -o remount,rw /

passwd

После этого вы сможете задать новый пароль пользователя root.

Затем последовательно выполняем две следующих команды, вторая из которых перезагрузит сервер vCSA:

umount /

reboot -f

Затем вы можете логиниться пользователем root с новым паролем.

Администраторы платформы виртуализации VMware vSphere в рамках ежедневной рутины занимаются процессами обновлений виртуальной инфраструктуры и ее компонентов путем накатывания патчей или проведения апгрейдов (в том числе наиболее сложных - на новые мажорные версии). Наиболее удобный способ делать это - использовать решение vSphere Lifecycle Manager (vLCM), который автоматизирует этот процесс. Это следующее поколение продукта vSphere Update Manager (VUM), который ранее использовался для планирования и накатывания обновлений...

С будущим крупным выпуском vSphere компания VMware планирует ввести режим строгой безопасности для vCenter (strong security mode), отражающий позицию безопасности VMware, который будет рекомендован к применению партнерам и клиентам в их операциях по управлению виртуальной инфраструктурой.

В строгом режиме не поддерживается SHA-1 как функция криптографического хеширования. VMware рекомендует заменить ее более безопасным и поддерживаемым SHA-256. Строгий режим также поддерживает полные SSL-сертификаты в качестве механизма обмена доверием, что может повлиять на некоторые API vSphere, использующие certificate thumbprints в качестве аргументов или как часть ответа API. Такие API могут не поддерживаться при включенном строгом режиме.

Параллельно со строгим режимом будет поддерживаться совместимый режим безопасности (compatible security mode) в целях обратной совместимости. Совместимый режим все еще поддерживает SHA-1 в качестве функции криптографического хеширования и опирается на certificate thumbprints для SSL-сертификатов как на действительный источник доверия. Использование совместимого режима не будет рекомендовано. Переключение между режимами будет происходить через свойство виртуального модуля vCenter Server Appliance. Подробная информация будет предоставлена в документации следующего выпуска vSphere.

Как будут выглядеть апгрейды существующих инфраструктур?

Начиная с грядущего крупного выпуска, все новые развертывания экземпляров vCenter будут настроены с включенным по умолчанию режимом строгой безопасности. При этом будут затронуты все решения партнеров, зависящие от устаревших алгоритмов криптографического хеширования, таких как SHA-1 или MD5. Клиенты смогут переключиться на compatible-режим, но он будет считаться устаревшим и не рекомендоваться VMware.

Обновленные до следующей версии экземпляры vCenter, ранее функционировавшие в уже существующих развертываниях, будут продолжать работать в режиме совместимости, установленном по умолчанию, если клиент не переключился на строгий режим до обновления vCenter. Таким образом, VMware рассчитывает, что клиенты будут применять самые строгие настройки безопасности, доступные в настоящее время. Это изменение повлияет и на плагины vSphere Client, использующие SHA-1 при регистрации в менеджере расширений vSphere. Отказ от адаптации к требованиям режима строгой безопасности vCenter повлечет за собой риск того, что соответствующий плагин vSphere Client станет непригодным для использования.

Влияние на плагины vSphere Client

Переход с SHA-1 на SHA-256

Все партнеры VMware должны иметь в виду, что начиная с предстоящего крупного выпуска, плагины vSphere Client, использующие устаревший стандарт SHA-1, не будут поддерживаться, когда в инфраструктуре клиента включен режим строгой безопасности vSphere. Чтобы решить эту проблему и обеспечить совместимость своих решений, VMware настоятельно советует партнерам убедиться, что версии плагинов vSphere Client, которые они предлагают сейчас, поддерживают SHA-256 в качестве алгоритма шифрования.

Алгоритм SHA-1 находится в состоянии устаревания с момента выпуска vSphere 7.0 Update 1. VMware дала возможность для плагинов vSphere Client регистрироваться в менеджере расширений с использованием SHA-256 в качестве алгоритма хеширования с выпуском vSphere 7.0 Update 3. Как следующий шаг в этом процессе, для предстоящего крупного выпуска vSphere, плагинам необходимо отказаться от использования SHA-1 в качестве функции криптографического хеширования.

Переход от certificate thumbprints к полным SSL-сертификатам

Вместе с миграцией с SHA-1, функции расширений клиента vSphere постепенно переходят к использованию полных SSL-сертификатов для регистрации плагинов. Полная поддержка сертификатов была введена для Client SDK с выпуском vSphere 8.0 Update 2. Выполнение полной проверки SSL-сертификата во время SSL handshake более безопасно, чем проверка отпечатка SSL-сертификата, даже если плагин уже использует отпечаток SSL-сертификата SHA-256.

Чтобы обеспечить совместимость плагинов в обе стороны сейчас партнерам рекомендуется предоставлять свои решения с возможностью регистрации у менеджера расширений клиента vSphere, используя как сертификат, так и отпечаток. Это необходимо, потому что в некоторых средах могут быть экземпляры vCenter, которые не поддерживают сертификаты, и которые могут попытаться загрузить новую версию плагина, зарегистрированную только с сертификатом.

Например, они могут применить certificate thumbprint (используя SHA-256 в качестве алгоритма хеширования) для регистрации с vCenter, работающим на версии 8.0 U1 или ранее, и полный SSL-сертификат для vCenter 8.0 U2 или более поздней версии.

Локальные плагины уходят в прошлое

Плагины vSphere Client, основанные на устаревшей локальной архитектуре плагинов вскоре уже не будут поддерживаться. Локальные плагины были объявлены устаревшими с момента выпуска vSphere 8.0 GA, и их поддержка прекращается со следующим крупным релизом vSphere.

Всем партнерам VMware необходимо предоставить своим клиентам версию плагина, основанную на удаленной архитектуре плагинов, чтобы они могли продолжить использование партнерского решения в следующем релизе vSphere.

Переход на TLS 1.3

Начиная с предстоящего обновления vSphere, VMware будет поддерживать протокол безопасности транспортного уровня TLS версии 1.3 вместе с устаревшим TLS 1.2, который включен по умолчанию. В следующем крупном выпуске TLS 1.2 и TLS 1.3 будут сосуществовать, и конфигурация vCenter по умолчанию будет поддерживать обе версии протокола. Однако в следующем релизе vSphere будет введен настраиваемый режим vCenter, поддерживающий только TLS 1.3.

VMware настоятельно рекомендует партнерам подумать о добавлении поддержки TLS 1.3 в их плагины, чтобы эти решения нормально работали во всех конфигурациях vCenter.

С выпуском обновления платформы виртуализации VMware vSphere 8 Update 2 компания VMware ввела еще один способ апгрейда сервисов управления виртуальной инфраструктурой vCenter Server Appliance 8.0 до Update 2, который теперь можно сделать методом Switchover. Это подразумевает развертывание нового экземпляра vCSA, на который по окончании апгрейда будет переключено управление виртуальной инфраструктурой vSphere.

Проапгрейдить на Update 2 вы можете vCenter 8 следующих версий (естественно, вы сможете апгрейдить и сам vCSA 8 U2 на последующие релизы в дальнейшем):

• 8.0 GA 8.0 U2
• 8.0 U1 8.0 U2
• 8.0 P02 8.0 U2

Суть нового метода описана в KB 92659, мы приведем здесь лишь основные шаги:

1. Монтируем ISO-образ c vCenter Server Appliance 8.0 до Update 2

2. Делаем бэкап vCenter на уровне файлов (это обязательно)

3. Обновляем плагин vCenter Server Lifecycle Manager в Upgrade Planner

4. Настраиваем новый модуль vCenter Server Appliance 8.0 Update 2 (это можно делать и для минорных апдейтов)

5. Запускаем предварительную фазу апгрейда (Prepare upgrade stage) с установкой временного IP

6. Запускаем процесс Switchover, во время которого произойдет остановка предыдущего виртуального модуля vCenter Server, перебивка IP-адресации и переключение на новый экземпляр vCSA

Florian Grehl на сайте virten.net опубликовал полезную статью о том, как включить аутентификацию Active Directory / LDAP / LDAPS в инфраструктуре VMware vSphere 8. Приводим ниже ее перевод.

Эта статья описывает, как интегрировать VMware vCenter Server в вашу инфраструктуру аутентификации. Источниками идентификации могут быть развертывания Microsoft Active Directory или протокола OpenLDAP.

В комплекте с управляющим сервером vCenter Server идет внутренняя база данных пользователей, которая позволяет добавлять и управлять пользователями из пользовательского интерфейса. Управление пользователями и единый вход предоставляются встроенным компонентом Platform Service Controller. В большой среде вы, возможно, захотите подключить вашу инфраструктуру виртуализации к централизованно управляемому провайдеру идентификации.

Обратите внимание, что VMware объявила о прекращении поддержки Integrated Windows Authentication (IWA). IWA был методом аутентификации, при котором вы присоединяли vCenter Server к вашему домену Active Directory. Несмотря на то, что Active Directory все еще поддерживается для аутентификации, рекомендуется использовать AD через LDAP или идентификацию с помощью ADFS. Для дополнительной информации см. KB78506.

1. Получение сертификата LDAPS

В связи с рисками безопасности, LDAPS заменяет LDAP как новый протокол каталога. Настоятельно рекомендуется использовать LDAPS, который использует SSL для установления безопасного соединения между клиентом и сервером перед обменом любыми данными. В настоящее время в пользовательском интерфейсе vCenter нет функции получения сертификата, поэтому сертификат нужно загрузить самостоятельно.

Подключитесь к vCenter Server Appliance (или любой системе с установленным OpenSSL CLI) с помощью SSH и войдите как root. Выполните следующую команду, чтобы показать сертификат LDAP:

# openssl s_client -showcerts -connect [LDAPS-Server]:636

Эта команда отображает цепочку сертификатов и информацию о сессии SSL. Вы можете использовать либо сертификат CA, либо сертификат сервера. Использование сертификата CA имеет преимущество в том, что вам не нужно перенастраивать провайдер идентификации, когда сертификат LDAPS заменяется.

Копируем содержимое между строчками -----BEGIN CERTIFICATE----- и -----END CERTIFICATE----- в текстовый файл.

После этого сохраните полученный файл с расширением .crt.

2. Добавление провайдера идентификации

• Откройте vSphere Client.
• Войдите как Single Sign-On Administrator.
• Перейдите к Administration > Single Sign On > Configuration.
• На вкладке провайдера идентификации откройте Identity Sources.
• Нажмите ADD.

• Измените Identity Source Type на Active Directory over LDAP.

• Заполните остальные поля следующим образом:

Identity source name: Метка для идентификации (нужно указать имя домена)

Base distinguished name for users: Уникальное имя Distinguished Name (DN) начальной точки для поиска на сервере каталогов. Пример: Если ваше имя домена - virten.lab, то DN для всего каталога - "DC=virten,DC=lab".

Base distinguished name for groups: Уникальное имя (DN) начальной точки для поиска на сервере каталогов.

Domain name: Ваше имя домена. Пример: "virten.lab".

Domain alias: Ваше имя NetBIOS. Пример: "virten".

Username: Пользователь домена как минимум с правами просмотра.
Если вы получаете ошибку "Invalid DN syntax.", попробуйте ввести пользователя в формате DN: "uid=administrator,cn=users,dc=virten,dc=lab".

Password: Пароль пользователя домена.

Connect to: Выберите "Connect to any domain controller in the domain", если вы хотите использовать DNS для идентификации контроллеров домена или настроить статические основные и вторичные URL. При использовании статических записей вы можете либо запрашивать локальный каталог (порт 636), либо глобальный каталог (порт 3269). (Для устаревших незащищенных подключений используйте 389/3268). Пример: "ldap://dc.virten.lab:636".

• Нажмите "Browse" рядом с сертификатом (для LDAPS).
• Выберите файл .crt, полученный ранее от сервера LDAP.
• Нажмите "ADD" и завершите мастер настройки.
• В источниках идентификации ваш LDAP должен появиться в списке, и с этого момента вы можете назначать разрешения vCenter пользователям и группам из вашего каталога Active Directory.
• Выберите ваш AD и нажмите кнопку "SET AS DEFAULT", чтобы сделать его доменом по умолчанию для аутентификации в вашем vCenter, что означает, что каждый, кто не указывает имя домена для входа, автоматически аутентифицируется в этом домене.
• Для входа с пользователями AD вам нужно установить разрешения. Чтобы добавить пользователя/группу AD в качестве глобального администратора, перейдите к Administration > Access Control > Global Permissions.
• Нажмите "ADD".
• Выберите домен и начните вводить в поле поиска User/Group, чтобы выбрать Domain entity.

• Нажмите "OK".

Теперь вы должны иметь возможность входить с помощью учетной записи Active Directory. Чтобы решать проблемы, связанные с аутентификацией, проверьте файлы журнала на vCenter Server Appliance в папке /var/log/vmware/sso.

На сайте проекта VMware Labs вышло очередное обновление утилиты vSphere Diagnostic Tool 1.1.6. Напомним, что это python-скрипт, который запускает диагностические команды на виртуальном модуле Photon OS (на его базе построен, например, vCenter Server Appliance), а также в перспективе это будет работать и в среде VMware ESXi. О последнем обновлении vSphere Diagnostic Tool (VDT) мы писали вот тут.

Давайте посмотрим на новые возможности vSphere Diagnostic Tool 1.1.5:

Общие улучшения:

• Увеличен таймаут проверок с 10 до 20 секунд
• Исправлена проблема, когда версия/топология идентифицировались некорректно

Проверка VC VMDIR:

• Была добавлена проверки Domain Functional Level (DFL) для обнаружения дополнительных возможных проблем

Проверка сертификатов vCenter:

• Проверка идентификатора ключа на предмет того, что он не заполнен
• Новая проверка для подсчета объектов CRL в разделе TRUSTED_ROOT_CRLS

Скачать VMware vSphere Diagnostic Tool 1.1.6 можно скачать по этой ссылке.

В июне компания VMware сделала анонс большого обновления своей архитектуры VMware Cloud Foundation версии 5.0. Этот крупный релиз платформы предлагает дополнительную масштабируемость, безопасность и несколько ключевых улучшений, которые направлены на соответствие требованиям для инфраструктур IaaS, упрощают развертывание облачных услуг на собственных площадках и обеспечивают дополнительную защиту от кибератак.

На сайте проекта VMware Labs обновилась утилита vSphere Diagnostic Tool до версии 1.1.5. Напомним, что она представляет собой python-скрипт, который запускает диагностические команды на виртуальном модуле Photon OS (на его базе построен, например, vCenter Server Appliance), а также в перспективе это будет работать и в среде VMware ESXi. О последнем обновлении vSphere Diagnostic Tool (VDT) мы писали вот тут.

Давайте посмотрим на новые возможности vSphere Diagnostic Tool 1.1.5.

Общие улучшения:

• VDT теперь поддерживает vSphere 8.0 Update 1
• VDT 1.1.5 больше не поддерживает vCenter 6.7, хотя многие проверки все еще будут работать. 1.1.4 останется доступной для тех, кто все еще нуждается в ней для продуктовой линейки 6.x.
• Учетные данные теперь проверяются в самом начале. Пользователю сообщается, что проверки, требующие аутентификации, не будут запускаться, если проверка пароля трижды не удастся.
• Поведение при тайм-ауте изменилось. Теперь он предлагает пользователю пропустить проверку или позволить ей выполниться, вместо того чтобы требовать флаг --force.

Проверка базы данных vCenter:

• Проверка VCDB теперь показывает уровни статистики, а также политики хранения задач и событий.
• Выходные данные проверки VCDB теперь соответствуют результатам из KB 1028356.

Проверка vCenter VMDIR:

• Проверка vmdir теперь включает информацию о партнерах ELM и тестирует подключение к портам через 389, 443, 2012 и 2020 к ним.
• Старая проверка портов была удалена в пользу описанной выше.
• Проверка vmdir теперь ищет устаревшую (нативную) конфигурацию PSC HA в реестре likewise.

Проверка сертификата vCenter:

• Срок действия сертификата теперь отображается с каждым сообщением о сертификате.
• Сертификат vmdir от 6.0 больше не включен в список проверок сертификатов.

Исправление ошибок:

• VDT теперь декодирует в utf-8, а не в ascii, чтобы избежать ошибок парсинга.
• Обновлены ссылки на KB.

Скачать vSphere Diagnostic Tool 1.1.5 можно по этой ссылке.

Мы уже много писали о том, что после выхода платформы vSphere 8 компания VMware перешла на модель релизов Initial Availability (IA) / General Availability (GA). IA-релиз - это полностью Enterprise-ready продукт, который соответствует всем промышленным стандартам VMware уровня релиза GA, но доступен он, как правило, на 4-6 недель раньше, чтобы собрать обратную связь от первых клиентов и партнеров (и, конечно же, критичные для инфраструктуры баги). В этот промежуток времени публикуются все найденные важные проблемы.

Одна из причин такого перехода - это то, что раньше релиз мажорной версии многие пользователи пропускали, ожидая хотя бы Update 1, который часто исправлял некоторые проблемы первоначального релиза новой версии платформы. Теперь у пользователей будет достаточно времени, чтобы оценить - произошло ли за эти 1-2 месяца что-то критичное, и можно ли обновлять свои хост-серверы. Такая схема должна работать эффективнее, так как до очередного пакета Update X проходит в среднем полгода.

Таким образом, общая схема выпусков IA/GA для VMware vSphere теперь выглядит так:

Если говорить конкретно, то версия vSphere 8 IA вышла в октябре прошлого года, а версия vSphere 8 GA была доступна через месяц - в ноябре 2022 года. Между этими двумя релизами не было сообщений о критических ошибках и проблемах, а значит вроде как новая схема работает неплохо. Кстати, установочный ISO-образ сервера ESXi 8.0 IA ушел в релиз как GA без изменений.

Теперь, после анонса первого пакета обновлений vSphere 8 Update 1, компания VMware решила эту схему немного доработать. Так как подавляющее большинство критических багов было связано с работой гипервизора ESXi, то теперь сервер упрвления vCenter будет выходить в статусе GA, а вот входящие в него хосты - в статусе IA.

Надо еще учесть, что vCenter обновляется чаще, чем ESXi, а также не является критической точкой инфраструктуры - виртуальные машины могут работать некоторое время и без него, а сам виртуальный модуль vCSA (vCenter Server Appliance) можно обновить достаточно просто, не затрагивая корневые инфраструктурные сервисы.

В итоге: выпуск VMware vSphere 8 Update 1 будет включать в себя ESXi 8.0 Update 1 IA и vCenter 8.0 Update 1 GA.

Как вы знаете, на прошедшей конференции Explore 2022 компания VMware анонсировала новые версии платформы виртуализации vSphere 8 и решения для создания отказоустойчивых хранилищ vSAN 8. Недавно эти решения стали доступны для скачивания как Initial Availability (IA), поэтому сейчас самое время развертывать их в своих тестовых окружениях для проверки перед большим апгрейдом.

Начать можно с виртуальной тестовой лаборатории, то есть инсталляции в рамках одного сервера или рабочей станции, где сервисы ESXi, vCenter и vSAN поднимаются в виртуальных машинах.

Для этой цели известный блоггер и инженер VMware Вильям Ламм создал на PowerCLI специальный сценарий Automated vSphere & vSAN 8 Lab Deployment, который автоматизирует развертывание компонентов виртуальной лаборатории на базе vSphere и vSAN восьмой версии.

Как видно на картинке, скрипт предназначен, чтобы развернуть три виртуальных сервера ESXi, создать на их базе кластер vSAN, а также развернуть виртуальный модуль управления vCenter Server Appliance (vCSA).

Итак для этого вам понадобятся:

• Действующий vCenter Server не ниже седьмой версии
• Компьютер Windows, Mac или Linux с установленным PowerShell Core и фреймворком PowerCLI 12.1 Core
• Виртуальный модуль vCenter Server Appliance 8.0 Build 20519528 OVA
• Виртуальный модуль Nested ESXi 8.0 IA OVA

Перед исполнением сценария вам нужно заполнить все его параметры, относящиеся к вашей текущей инфраструктуре и к создаваемой тестовой лаборатории, а также распаковать содержимое ISO-образа виртуального сервера vCSA.

Пример исполнения сценария показан ниже:

В итоге процесс будет выполняться пошагово до его завершения с информацией о каждом шаге:

Ну и после всего этого в vSphere Client вы увидите вашу созданную виртуальную тестовую лабораторию с тремя хостами ESXi и сервером управления vCenter / vCSA:

Скачать сценарий Automated vSphere & vSAN 8 Lab Deployment можно по этой ссылке, там же есть более подробная информация о том, как его использовать.

В апреле компания VMware выпустила обновление своего основного фреймворка для управления виртуальной инфраструктурой и ее компонентами из командной строки PowerCLI 12.6. О прошлой версии PowerCLI 12.5 мы писали в январе вот тут, а сегодня расскажем, что появилось нового в весеннем обновлении.

Основные улучшения и нововведения:

1. Байндинги PowerShell для интерфейсов NSX Policy Manager API.

Теперь появился новый модуль VMware.Sdk.Nsx.Policy, который реализует байндинг PowerShell для программных интерфейсов NSX Policy Manager API.

2. Новые командлеты для управления виртуальным модулем vCenter Server Appliance.

Теперь для управления резервными копиями vCenter Server Appliance можно использовать следующие командлеты:

• New-ApplianceBackupJob - стартует задачу резервного копирования на уровне файлов vCenter Server на бэкап-сервер.
• Wait-ApplianceBackupJob - мониторит прогресс задачи резервного копирования и возвращает в ApplianceBackupJob.
• Get-ApplianceBackupJob - получает список завершенных или находящихся в исполнении задач резервного копирования.
• Stop-ApplianceBackupJob - останавливает задачи РК в соответствии с указанными параметрами.
• Get-ApplianceBackupPart - получает список частей (parts), которые могут быть включены в задачу РК, а также их размер в резервной копии. Обязательные части всегда включаются в бэкап.

3. Поддержка SRM 8.5.

Модуль VMware.VimAutomation.Srm был обновлен и теперь поддерживает решение VMware Site Recovery Manager 8.5.

4. Исправления ошибок.

VMware приводит таблицу с багофиксами:

Загрузить компоненты фреймворка VMware PowerCLI 12.6 можно по этой ссылке. Release notes доступны тут.

За последние пару месяцев на сайте проекта VMware Labs вышло несколько обновлений утилиты vSphere Diagnostic Tool. Напомним, что это средство представляет собой python-скрипт, который запускает диагностические команды на виртуальном модуле Photon OS (на его базе построен, например, vCenter Server Appliance), а также в перспективе это будет работать и в среде VMware ESXi. О первой версии vSphere Diagnostic Tool мы писали вот тут.

Основное назначение данной утилиты - дать администраторам быстрое средство траблшутинга, которое они могут использовать для первичной идентификации наиболее распространенных проблем. Если все проверки пройдут успешно, то дальше уже можно более глубоко изучать логи и проводить дополнительные тесты.

Давайте посмотрим, что нового появилось в vSphere Diagnostic Tool (сейчас актуальная версия 1.1.4) с момента ее последнего релиза:

• Исправлены проблемы со спецсимволами в паролях
• Тесты имеют таймаут 10 секунд, а ключ -f используется для пропуска таймаутов
• Название проверки выводится еще до ее запуска
• Проверка VC Disk Space Check теперь игнорирует раздел proc
• Проверка VC Info Check теперь имеет приятный вывод и возможность вывода во внешний канал PSC
• Улучшены проверки VC Core Check
• Исправлено множество ошибок, связанных с обработкой паролей и сертификатов

Скорее всего, данное средство включат в будущем в состав инфраструктурных продуктов линейки VMware vSphere для проверки виртуальных модулей на базе Photon OS (а это уже почти все продукты, построенные на базе хостовой ОС Linux, вроде vCSA).

Скачать утилиту vSphere Diagnostic Tool можно по этой ссылке.

Многим из вас знакома компания StarWind Software, выпускающая одни из лучших в отрасли продукты для организации отказоустройчивых хранилищ под платформы виртуализации. Компания производит как программные продукты (StarWind Virtual SAN для vSphere и Hyper-V), так и программно-аппаратные комплексы, представленные линейкой StarWind HyperConverged Appliance (HCA) и StarWind Storage Appliance. Сегодня мы поговорим именно о программно-аппаратных решениях StarWind Appliances...

Компания VMware объявила о первом релизе PowerCLI в этом году - на днях стала доступна для загрузки версия PowerCLI 12.5. Напомним, что о прошлой версии этого фреймворка для управления виртуальной инфраструктурой с помощью сценариев мы писали вот тут.

Давайте посмотрим, что там появилось нового:

1. Функции vCenter Server Appliance Service Management

В апдейте PowerCLI появилось 4 новых командлета:

• Get-VIApplianceService – получает список сервисов vCenter Server Appliance (vCSA)
• Start-VIApplianceService – запускает один из сервисов
• Stop-VIApplianceService – останавливает
• Restart-VIApplianceService – перезапускает
  

2. Поддержка VMware Cloud on AWS Outpost

Теперь PowerCLI поддерживает обращение к онпремизной инфраструктуре AWS, которая называется Outpost (стала доступной в конце прошлого года). Для этого есть командлет Get-VmcOutpost, который позволяет получить список доступных аутпостов для организации в VMC. Также при создании SDDC с помощью командлета New-VmcSddc есть параметр -Outpost, который позволяет создать объект в рамках аутпоста.

3. Поддержка Hot add / Remove для процессоров и памяти

Теперь есть новые параметры, в командлетах создания и настройки ВМ (Set-VM и New-VM), которые позволяют включить функции горячего добавления памяти и процессоров, а также удаления процессоров. Вот эти параметры:

• -CpuHotAddEnabled (включить CPU Hot Add)
• -CpuHotRemoveEnabled (включить CPU Hot Remove)
• -MemoryHotAddEnabled (включить Memory Hot Add)

4. Включение шифрованной миграции vMotion

Теперь для командлетов создания и настройки ВМ (Set-VM и New-VM) есть параметр -MigrationEncryption, который позволяет включить шифрованную миграцию.

5. Обновления для Horizon 8.4

Модуль Horizon был обновлен и теперь включает в себя байндинги для Horizon 8.4 API.

Больше информации о новом релизе вы можете узнать вот тут. Скачать VMware PowerCLI 12.5 можно по этой ссылке.

На сайте проекта VMware Labs обновилась полезная для администраторов VMware vSphere утилита VMware DRS Sump Insight до версии 2.1. Напомним, что это портал самообслуживания, куда пользователи могут загружать файлы дампов DRS. После этого будет выведена информация об операциях по перемещению виртуальных машин, которые рекомендует выполнить механизм балансировки нагрузки DRS. О прошлых версиях этой утилиты мы писали тут и тут.

В новой верси не так много нововведений:

• Добавлена поддержка дампов VMware vSphere 7.0 Update 2 и Update 3
• Минорные улучшение интерфейса и бэкенда
• Исправления ошибок

Напомним также о специальном плагине на базе HTML5 к vSphere Client для данного сервиса. Он добавляет функции утилиты DRS Dump Insight в интерфейс vSphere Client, работающего с сервером vCenter Server Appliance (vCSA).

Скачать VMware DRS Sump Insight 2.1 можно по этой ссылке.

На сайте проекта VMware Labs появилось еще одно полезное средство для администраторов виртуальной инфраструктуры - vSphere Diagnostic Tool. Оно представляет собой python-скрипт, который запускает диагностические команды на виртуальном модуле Photon OS (на его базе построен, например, vCenter Server Appliance), а также в перспективе это будет работать и в среде VMware ESXi.

Основное назначение данной утилиты - дать администраторам быстрое средство траблшутинга, которое они могут использовать для первичной идентификации наиболее распространенных проблем. Если все проверки пройдут успешно, то дальше уже можно более глубоко изучать логи и проводить дополнительные тесты.

Интересно, что данный продукт уже был протестирован во внутренней команде поддержки VMware, которая опробовала его на реальных пользователях.

Для vCenter Server Appliance 6.5 или более поздней версии можно выполнить следующие тесты:

• Базовая информация о vCenter
• Проверка Lookup Service
• Проверка AD
• Проверка сертификатов vCenter
• Проверка основных файлов (Core File)
• Проверка диска
• Проверка vCenter DNS
• Проверка vCenter NTP
• Проверка портов vCenter
• Проверка аккаунта Root
• Проверка служб vCenter
• Проверка механизма VCHA

В качестве результатов будет выдан один из статусов Pass/Warning/Fail, а также для статусов Warning и Fail выводятся ссылки на статьи KB, которые могут пригодиться для решения проблем в данной категории.

Команда заявляет, что в бэклоге проекта еще более 100 планируемых фич, поэтому следите за обновлениями скриптов. Скорее всего, данное средство включат в будущем в состав инфраструктурных продуктов линейки VMware vSphere для проверки виртуальных модулей на базе Photon OS (а это уже почти все продукты, построенные на базе хостовой ОС Linux, вроде vCSA).

Скачать vSphere Diagnostic Tool можно по этой ссылке.

Компания VMware, вскоре после большого обновления vSphere 7 Update 3, выпустила небольшой апдейт vSphere 7 U3a. С момента прошлого релиза прошло около месяца, поэтому нововведений не так много. Напомним, что в Update 3 для администраторов и DevOps появилась возможность использовать команды Kubernetes для развертывания ВМ на хостах, где включена поддержка vGPU.

Теперь в Update 3a эта возможность позволяет вновь созданным виртуальным машинам стать частью кластера TKG (Tanzu Kubernetes Grid) с нативным исполнением команд. Это позволит:

• Компаниям использовать кластеры TKG как платформу Kubernetes с GPU-ускорением для нагрузок AI/ML.
• Администраторам получить инструмент быстрой и эффективной совместной работы над развертыванием и обслуживанием инфраструктуры контейнеров и уйти от рабочего процесса коммуникации на базе тикетов.

Инфраструктура Tanzu Kubernetes (TKr) теперь построена на Ubuntu 20.04 - сам образ был оптимизирован для использования с нагрузками AI/ML и тщательно оттестирован. Детальное руководство об использовании сервисов Tanzu для AI/ML находится в этой статье.

Также обновление содержит патч VMware vCenter Server Appliance 7.0 Update 3a, который включает в себя фиксы ошибок и исправления в подсистеме безопасности.

Скачать VMware vSphere 7 Update 3a можно по этим ссылкам:

• VMware vCenter 7 Update 3a
• VMware ESXi 7 Update 3a

Release Notes находятся тут.

В последнее время в продуктах VMware часто находят различные уязвимости, а хакеры по всему миру разрабатывают различные руткиты и утилиты для взлома инфраструктуры VMware vSphere и серверов ESXi. В связи с этим многие администраторы хотели бы отключить неиспользуемые плагины, которые есть в VMware vCenter. Совсем недавно появились следующие оповещения о проблемах с безопасностью (VMware Security Advisories, VMSA), которые касаются плагинов:

• CVE-2021-21972 - VMSA-2021-0002 (плагин vRealize Operations Manager)
• CVE-2021-21985 - VMSA-2021-0010 (плагин Virtual SAN Health Check)
• CVE-2021-21986 - VMSA-2021-0010 (плагины Virtual SAN Health Check, Site Recovery, vSphere Lifecycle Manager и VMware Cloud Director Availability)

Подробно об отключении плагинов у VMware написано в KB 83829. Приведем здесь данную процедуру вкратце.

В конфигурационный файл на сервере vCenter вам нужно будет добавить одну или несколько следующих строчек, в зависимости от плагина, который вы хотите отключить:

Чтобы отключить сразу все указанные плагины, нужно будет добавить следующий текстовый блок:

<PluginPackage id="com.vmware.vrops.install" status="incompatible"/>

<PluginPackage id="com.vmware.vsphere.client.h5vsan" status="incompatible"/>

<PluginPackage id="com.vmware.vrUi" status="incompatible"/>

<PluginPackage id="com.vmware.vum.client" status="incompatible"/>

<PluginPackage id="com.vmware.h4.vsphere.client" status="incompatible"/>

Давайте теперь посмотрим, какие плагины включены по умолчанию на всех серверах vCenter после установки (Default), а какие устанавливаются и включаются только после установки соответствующего продукта (Product):

Итак, чтобы отключить плагины, вам нужно:

• Подключиться к серверу vCenter Server Appliance (vCSA) по SSH как root
• Сделать резервную копию файла, например, командой:
  cp -v /etc/vmware/vsphere-ui/compatibility-matrix.xml /etc/vmware/vsphere-ui/compatibility-matrix.xml.backup
• Открыть этот файл в текстовом редакторе командой:
  vi /etc/vmware/vsphere-ui/compatibility-matrix.xml
• Добавить туда соответствующую строчку конфигурации из таблицы выше вот в этом месте (раздел pluginsCompatibility):

• Сохранить файл с помощью команды vi:
  :wq!
• Перезапустить сервисы vsphere-ui:
  service-control --stop vsphere-ui
service-control --start vsphere-ui

Если вы все еще используете VMware vCenter for Windows, то указанную процедуру нужно проделать в следующем файле (не забывайте сделать его бэкап):

C:\ProgramData\VMware\vCenterServer\cfg\vsphere-ui\compatibility-matrix.xml

Делается это в том же месте, что и для матрицы совместимости в vCSA:

После этого также перезапускаем службу vsphere-ui для Windows:

C:\Program Files\VMware\vCenter Server\bin> service-control --stop vsphere-ui
C:\Program Files\VMware\vCenter Server\bin> service-control --start vsphere-ui

В том, что плагины отключены вы сможете убедиться в интерфейсе vSphere Client в разделе Administration > Solutions > client-plugins:

Ну и для тех, кому удобнее воспринимать руководство в видеоформате, компания VMware сделала ролик на эту тему:

На днях компания VMware выпустила минорное обновление vCenter 7 Update 2c, которое из нового содержит только багофиксы и исправления в подсистеме безопасности (рекомендуется его накатить в связи с участившимися случаями нахождения и эксплуатации уязвимостей).

Дункан Эппинг рассказал о том, как побороть ошибку, которая иногда возникает при обновлении сервера vCenter на версию vCenter Server 7.0 Update 2c:

Test RPM transaction failed. Collect the logs for diagnostics

Нажатие на кнопку "Resume" ни к чему не приводит, ошибка возникает циклически. Чтобы эту ошибку устранить, нужно удалить файл software_update_state.conf на сервере vCenter Server Appliance. Для этого зайдите туда по SSH и выполните команду:

rm /etc/applmgmt/appliance/software_update_state.conf

Затем перезагружаете виртуальный модуль vCSA командой:

reboot

И снова запускаем установщик:

appliancesh
software-packages install --url --acceptEulas

После этого обновление будет завершено корректно. Скачать VMware vCenter 7 Update 2c можно по этой ссылке.

Некоторые администраторы VMware vSphere хотели бы закрыть доступ для некоторых пользователей к интерфейсу vSphere Client или ограничить его определенными адресами, оставив доступ через API. Например, это нужно тогда, когда пользователи vSphere не соблюдают установленные процедуры и регламенты при работе в интерфейсе клиента (например, не фиксируют внесенные в конфигурации виртуальных машин изменения).

Вильям Ламм рассказал о простом способе ограничения доступа к UI клиента vSphere Client. Делается это через настройки сервера Apache Tomcat, на базе которого построен виртуальный модуль vCenter Server Appliance. Называется это Access Control Valve - по ссылке можно подробно изучить опции, которые можно применять, а мы же рассмотрим простой пример ниже.

Идем по SSH на vCSA и открываем там следующий файл:

/usr/lib/vmware-vsphere-ui/server/conf/context.xml 

В него добавляем следующую запись:

<Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1|localhost|x.x.x.x|y.y.y.y"/>

Значения x.x.x.x, y.y.y.y и далее за ними можно указать как разрешенные адреса для соединения с сервером. Блок "127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1|localhost" должен присутствовать всегда для обеспечения локального соединения сервисов самого vCenter.

Адреса, не занесенные в этот список, при соединении через веб-браузер получат 403 ошибку, при этом доступ через PowerCLI и API останется для этих адресов (поскольку это только настройка веб-сервера):

Да, и надо не забыть, что для того, чтобы изменения веб-сервера вступили в силу, надо его перезапустить командой:

service-control --restart vsphere-ui

Если вы часто имеете дело с технической поддержкой VMware, то знаете, что довольно часто требуется собирать с хостов VMware ESXi дампы. Нередко администраторы настраивают удаленную отсылку дампов на сервер VMware vCenter Server Appliance (vCSA). По умолчанию размер раздел для дампов на нем равен 2 ГБ, что может оказаться мало, если инфраструктура у вас большая.

Вильям Лам задался этим вопросом и вспомнил, что есть такая настройка Repository max size в разделе ESXi Dump Collector для старого клиента vSphere Web Client:

Между тем, в новый vSphere Client на базе HTML 5 эту настройку не перенесли. Поэтому если вы используете VMware vCSA версий 6.7 или 7.0 с новым клиентом, то вам нужно открыть файл /etc/sysconfig/netdumper и изменить там следующий параметр:

NETDUMPER_DIR_MAX_GB 

Максимальный его размер может составлять 10GB.

После изменения размера раздела для дампов нужно перезапустить сервис дампера. На vCSA 7 делается одной командой:

service-control --restart vmware-netdumper

На vCSA 6.7 двумя:

service-control --stop vmware-netdumper
service-control --start vmware-netdumper

Некоторое время назад мы писали о новой версии решения VMware Cloud Foundation 4.2 (VCF), которое включает в себя компоненты VMware vRealize Suite, VMware vSphere Integrated Containers, VMware Integrated OpenStack, VMware Horizon, NSX и другие, работающие в онпремизной, облачной или гибридной инфраструктуре предприятия под управлением SDDC Manager. 

На днях VMware сделала небольшое обновление этого пакета - VMware Cloud Foundation 4.2.1, давайте посмотрим, что там нового:

• Обновления безопасности для Photon OS в SDDC Manager 4.2.1 (пакет PHSA-2021-3.0-185 обновлен до PHSA-2021-3.0-209 - подробнее тут).
• Критические обновления безопасности для VMware vCenter Server Appliance (мы писали об уязвимости тут).
• Обновление некоторых версий продуктов в составе пакета.

Новый Bill of Materials включает в себя следующие версии решений VMware:

Для пользователей пакета версии 3.10.2 также есть обновление - VCF 3.10.2.1, о нем прдробно рассказано вот тут. Вот его Bill of Materials:

Об обновлении подсистемы безопасности VMware vCenter Server Appliance 6.7 Update 3n рассказано тут.

Недавно мы писали о VM Service - службе, которая дает разработчикам и администраторам, работающих со средой контейнеров Kubernetes в решении vSphere with Tanzu, возможности по развертыванию виртуальных машин. Она была анонсирована в vSphere 7 Update 2a.

Многие пользователи жалуются, что консоль виртуальных машин, развернутых через VM Service в кластере vSphere with Tanzu, оказывается недоступна для логина, даже для администраторов. Над этой проблемой работают, но пока в интерфейсе это выглядит так:

Между тем, попасть в консоль иногда нужно (например, для отладки или траблшутинга) - и для этого есть воркэраунд.

Итак, заходим по SSH на VMware vCenter Server Appliance (vCSA) и выполняем следующие команды, которые получают root-пароль от Supervisor Cluster, выводят его в консоли и инициируют сессию к одному из узлов супервизор-кластера:

SV_DECRYPT_OUTPUT=$(/usr/lib/vmware-wcp/decryptK8Pwd.py)

SV_CLUSTER_IP=$(echo ${SV_DECRYPT_OUTPUT} | awk -F 'IP: ' '{print $2}' | awk '{print $1}')

SV_CLUSTER_ROOT_PASSWORD=$(echo ${SV_DECRYPT_OUTPUT} | awk -F 'PWD: ' '{print $2}' | awk '{print $1}')

echo -e "\n${SV_CLUSTER_ROOT_PASSWORD}\n"

ssh root@${SV_CLUSTER_IP}

Далее, после того, как мы залогинились в Supervisor Cluster, нужно получить креды от нужного нам узла. Делается это следующим набором команд:

VM_SERVICE_ACCOUNT_USERNAME=$(kubectl get secrets wcp-vmop-sa-vc-auth -n vmware-system-vmop -o jsonpath='{.data.password}' | base64 -d)
VM_SERVICE_ACCOUNT_PASSWORD=$(kubectl get secrets wcp-vmop-sa-vc-auth -n vmware-system-vmop -o jsonpath='{.data.username}' |base64 -d)
echo -e "\n${VM_SERVICE_ACCOUNT_PASSWORD}\n${VM_SERVICE_ACCOUNT_USERNAME}\n"

После этого заходим в vSphere Client под этими кредами и функция запуска консоли для данной ВМ вам будет доступна:

Источник.

Релиз платформы VMware vSphere 6.5 в свое время (а это была осень 2016 года) оказался довольно удачным, поэтому до сих пор довольно большое количество пользователей используют его в производственной среде.

В июне прошлого года VMware объявила о продлении поддержки vSphere 6.7 в связи с пандемией, но кто ж знал, что все настолько поменяется, поэтому о продлении срока поддержки версии 6.5 сообщили только сейчас.

Теперь период general support period для vSphere 6.5 продлен на 11 месяцев до 15 октября 2022 года, что совпадает с аналогичным для vSphere 6.7. До этого момента достижение точки прекращения предоставления полной технической поддержки (EoGS, End of General Support) было намечено на 15 ноября 2021 года. Но окончание технического сопровождения (EoTG, End of Technical Guidance) не изменилось - оно наступит 15 ноября 2023 года.

У VMware нет планов продлевать период Extended Support для vSphere 6.5, поэтому тем, кому это важно, следует смигрировать хотя бы на vSphere 6.7, где расширенная поддержка будет действовать подольше.

Расширение поддержки для vSphere 6.5 будет с некоторыми ограничениями:

• Нужно будет использовать vCenter 6.7 для хостов ESXi 6.5, потому что там есть обновленный vSphere Client вместо старого Web Client.
• Для хостов на базе vCenter Server Appliance нужно будет обновиться на vCenter Server to 6.7 Update 3 (см. тут подробнее).
• vCenter Server for Windows нужно проапгрейдить до vCenter Server to 6.7 Patch 05 или более поздней версии (см. тут).
• Если вы не сможете обновить vCenter, то будет допустимо использовать vCenter 6.5, но как-то поддерживать работоспособность Flash-клиента (см. тут).

Аналогично продляются сроки оказания технической поддержки для VMware vSAN 6.5 и 6.6 до тех же дат и с теми же условиями, что и для vSphere: теперь окончание поддержки наступит 15 октября 2022 года, но EoTG также не изменится:

Ограничения расширения поддержки для vSAN остаются теми же, что и для VMware vSphere.